The ARM® 64-bit processor systems are operable at multiple hierarchical privilege levels. Typically, such systems execute user applications at a lowest privilege level, known as exception level 0 (EL0), and execute system code at three increasingly higher privilege levels, known as EL1, EL2, and EL3. For example, operating system code may execute at EL1, hypervisor code at EL2, and secure monitor code at EL 3.
In general, operating systems and hypervisors use “secure monitor calls” (SMCs) to communicate with secure monitors—code that executes in a secure mode intended to mitigate security concerns (e.g., confidentiality, integrity, authenticity, etc.). Similarly, in systems where an operating system (OS) is running in a virtual machine (VM) under a hypervisor, the OS uses “hypervisor calls” (HVC), also known as hyper calls, to communicate with the hypervisor. However, secure monitor and hypervisor implementations as well as the corresponding SMC and HVC interfaces may vary dramatically across systems. For instance, in some systems, the secure monitor code and SMC interface provide a trusted computing base. In other systems, the secure monitor code and SMC interface provide debugging facilities. Yet other systems do not include any secure monitor code.
In operation, if an OS or a hypervisor issues a SMC or HVC that is not exposed by a corresponding interface, then undesirable behavior, such as a system crash occurs. Consequently, various techniques are employed to detect the presence and type of SMC and HVC implementations before issuing SMC or HVC calls, such as out-of-band methods. However, out-of-band methods typically rely on implementation-specific details for secure monitors, hypervisors, and/or virtual machine and accesses to nonexistent implementation-specific features, such as registers, may cause unrecoverable failures. Consequently, a more flexible and robust strategy for detecting hypervisor and secure monitor implementations is desirable.